1. Field of the Invention
The present invention relates to the field of software monitoring and tracing, and more specifically, to a time-based trace facility for recording state data to build an historical record for software in a computer environment.
2. Description of the Related Art
Users of computing applications often encounter various sorts of problems and inconsistencies while using the applications. Designing computer software that will minimize user problems requires knowledge as to how the user is making use of the application and the tasks that are trying to be accomplished by use of the applications. The design process typically includes iterative design and user testing of those designs in order to identify where users have problems so that design flaws can be accurately addressed and fixed. A thorough knowledge of problems that users encounter in existing products is also critical if design mistakes are to be avoided for future versions of those applications.
Understanding what is important to users of a particular software application product is a challenge for software application developers. Typically, enhancements to a product release are based on feedback from surveys, forums or from user design center sessions in which participants are given a set of tasks to accomplish while using the application. Some problems inherent in these methods, however, include the inability of users to articulate their needs, the artificiality of surveys produces feedback that is not meaningful, and users of forums are typically technical fans of the product so that the results may be of little practical use to the product developers.
Most would agree that the best way to get feedback is by observing what a user does throughout actual use sessions with the product, that is by watching the user as the user works through the application in the setting for which it was intended. The problem is to provide a meaningful solution for gathering real user feedback in real time on a regular basis, and providing this data back to the program developer where it can be analyzed and used in enhancing and improving the application. One effective way of gathering such information about user interaction with the application is through code instrumentation. The term “instrumentation” is understood to mean the incorporation of statements or routines in an application to cause outputs to be provided when the application is running on a computer system thereby illustrating the interaction of the end user with the application. These outputs may be displayed in real-time, which is referred to as “monitoring”, or recorded to memory to form an historical record, which is referred to as “tracing”.
Within the computer system the applications run in address space. An address space is a range of contiguous virtual storage addresses that the system creates for a user. Contiguous virtual storage addresses are mapped into real addresses in real memory (e.g. RAM), which may not be contiguous. The address space contains system and application executable code, application user data and application and system state data. Application instructions execute in an address space.
Currently, it is known that instrumenting an application involves going into the application and adding appropriate program code at every point in the application where useful user data can be gathered, and then recompiling the application. This is referred to as “event-based” or “location-based” monitoring or tracing. The monitor/trace function is placed in a specified location within the application and the function is triggered when the application's execution reaches that location.
It has been found that this “compile-time” method of instrumentation is not really effective for a number of reasons. It takes many points of instrumentation to get sufficient and meaningful overall coverage of user interaction with the application. At the particular code level, it is difficult to be judicious in selecting code points for instrumentation. A large number of instrumentation points can negatively affect the application's performance. The amount of data produced depends entirely on where the user is spending time in working with the application. In some instances, the data can be large and therefore cumbersome to analyze, and at other times, it may be sparse and therefore of very little practical use.
To address the limitations of “compile-time” instrumentation it is suggested to dynamically insert a time-based monitor function into an address space of a running application. This is done a run-time, hence does not require recompilation. The time-based monitor function is triggered at a preset time interval, regardless of where the application execution is at that moment, with each invocation generating an updated display in the output window of the current state of one or more monitored global variables. Because data capture is asynchronous with the process events, the data may not reflect the exact state when a critical event occurs. Once monitoring is completed the monitor function is removed.